System for processing conditional payment request in an electronic financial transaction

ABSTRACT

A mechanism is presented for processing conditional payment requests in an electronic financial transaction system. In particular, the mechanism provides for the handling of concurrent conditional payment events. The status of a payment condition may be categorized into three categories, and a priority assigned relative to the category. In this way, concurrent events may be prioritized according to their respective categories. Events may then be executed in order of assigned priority.

TECHNICAL FIELD

The present invention relates in general to data processing systems forfinancial transactions mediated over an Internetwork, and in particularto a data processing system and methods therein for processingconditional payment requests in an electronic financial transaction.

BACKGROUND INFORMATION

The advent of business-to-business (B2B) electronic commerce has led tothe development of technologies for the automated payment transactionsbetween buyers and sellers engaged in electronic commerce. Inparticular, mechanisms have been promulgated for the initiation ofpayments related to B2B e-commerce transactions using the Internet. Onesuch technology is the Eleanor initiative. Eleanor is a set ofspecifications for implementing interoperable B2B electronic paymentservices which may be communicated between the parties using theInternet. Eleanor is promulgated by Identrus LLC, New York, N.Y., andthe Eleanor specification may be obtained through it.

In a transaction conducted in accordance with the Eleanor mechanism,transactions are conveyed in messages in accordance with the Eleanorspecifications. In any transaction, the entities that may participateare a buyer (“BU”), a seller (“SE”), a seller financial institution(“SFI”) and a buyer financial institution (“BFI”). Note that in atransaction, a particular financial institution might be acting onbehalf of both the buyer and seller. That is, a particular buyer andseller pair could have the same financial institution. The entity onwhose behalf the financial institution is acting may be referred to asthe “role” of the institution in any given transaction.

Additionally, transactions may be initiated by either the seller orbuyer. If initiated by the buyer, the transaction may, but need not,include securely signed information from the seller. (For the purposesherein, a securely signed information from the seller may be understoodto be a digital signature which may be based on a public-key algorithm,and a trusted certification authority; the details of the signingalgorithms are not required). Note that the source of a particularmessage may be any one of entities participating in a transaction, thatis a buyer, seller, buyer's financial institution or seller's financialinstitution, and this may be independent of the initiator of thetransaction. The initiator of the transaction may be signified in amessage by the “model.”. If the transaction is initiated by the Seller,the model may be referred to as a seller financial institution model(“SFIM”). Similarly, if the buyer initiated the transaction, the modelreferred to as the buyer financial institution model (“BFIM”). There maybe two submodels of the buyer financial institution model depending onwhether the transaction is initiated by the buyer and signed by theseller, the buyer financial institution model with seller signature(“BFIMsig”) or, alternatively if unsigned by the seller, the buyerfinancial institution model without seller's signature. The model may beused, among other things, to allow a financial institution todistinguish the order in which messages must be forwarded betweenitself, its subscriber, or other financial institutions, or the typesand order of the validity checks it must perform. Requests for paymentin the BFIM model are usually instructions from a Buyer for the Buyer'sfinancial institution to release money.

These requests may be in the form of payment order from the Buyerrequesting the BFI to execute a credit payment to the Seller. Inparticular, a payment order may be made subject to a condition(conditional payment order) whereby the payment will not be releaseduntil the conditions have been met, or waived.

The payment condition may be in any of several status. For example, inthe Eleanor Specification, discussed hereinabove, there are sevencondition status: Registered, CDPProcessing, Cancelled, Waived,Discharged, Expired and Failed. Different parties, for example, buyersand condition discharging parties can concurrently access a paymentsystem and submit requests which may trigger condition statustransitions. (A condition discharging party may be a party that, for aparticular conditional payment, may discharge the condition, that is,“inform” the payment system that the particular condition has been met.The condition discharging party may be, but is not necessarily, thebuyer.) The buyer may submit a cancel request to transition the statusto cancelled status. If, for example, these two events occursubstantially concurrently, the operating system will select one toexecute, and the other will wait until the first change in status iscomplete. The subsequent execution of the second event may fail becauseof the change in status due to the execution of the first. This maypresent a performance bottleneck to the payment system.

Therefore, there is a need the art for mechanisms to prioritize theprocessing of conditional payment requests in an electronic paymentsystem.

SUMMARY OF THE INVENTION

The aforementioned needs are addressed by the present invention.Accordingly, there is provided in one embodiment, a computer programproduct embodied in a tangible storage medium. The program productincludes programming for processing concurrent conditional paymentevents. The program instructions are executable to perform the operationof enqueueing the concurrent conditional payment events in a queueaccording to a predetermined priority policy. An enqueued conditionalpayment event having a first priority position in the queue is executedand the remaining conditional payment events having a same priority fromthe queue are deleted. Conditional payment events constitute apredetermined set of requests for performing a corresponding action on aconditioned payment in an electronic transaction system. In a furtherinvention, the step of deleting remaining events in the queue isbypassed if the execution of the conditional payment event having afirst priority position fails.

The foregoing has outlined rather broadly the features and technicaladvantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 schematically illustrates an Internet-based e-commercearchitecture which may be used in conjunction with the presentinvention;

FIG. 2 illustrates, in flowchart form, a methodology for conditionalpayment processing in accordance with an embodiment of the presentinvention;

FIG. 3 illustrates a priority table which may be used in conjunctionwith the methodology of FIG. 2;

FIG. 4 illustrates, in flowchart form, a methodology for populating apriority queue in accordance with the present inventive principles; and

FIG. 5 illustrates, in block diagram form, a data processing systemwhich may be used in an embodiment of the present invention.

DETAILED DESCRIPTION

A mechanism is presented for processing conditional payment requests inan electronic financial transaction system. In particular, the mechanismprovides for the handling of concurrent conditional payment events. Thestatus of a payment condition may be categorized into three categories,and a priority assigned relative to the category. In this way,concurrent events may be prioritized according to their respectivecategories. Events may then be executed in order of assigned priority.

In the following description, numerous specific details are set forthsuch as particular communication protocols, etc., to provide a thoroughunderstanding of the present invention. However, it will be recognizedby those of ordinary skill in the art that the present invention may bepracticed without such specific details. In other instances, well-knowncircuits have been shown in block diagram form in order not to obscurethe present invention in unnecessary detail. For the most part, detailsconcerning timing considerations and the like have been omitted inasmuchas such details are not necessary to obtain a complete understanding ofthe present invention and are within the skills of persons of ordinaryskill in the relevant art. Refer now to the drawings wherein depictedelements are not necessarily shown to scale and wherein like or similarviews are designated by the same reference numeral through the severalviews.

An architecture for Internetworked B2B e-commerce transactions which maybe used in conjunction with the present invention is schematicallyillustrated in FIG. 1. As previously discussed, the set of participantsin a particular transaction may include a buyer 102, seller 104,seller's financial institution (“SFI”) 106 and a buyer's financialinstitution (“BFI”) 108. A transaction between a buyer and a seller andthe initiation of a payment therefore may be effected electronically byan exchange of payment transactions messages 110 (or simply “messages”)between the parties. Additionally, as discussed hereinabove, paymentsmay be conditioned on the occurrence of an event, say an insurancepolicy has been issued, for example. The event may be performed by athird party (e.g. insurance underwriter) which may discharge thecondition electronically (the Condition Discharging Party (“CDP”)).Thus, a CDP 114 may also exchange payment transaction messagesrespecting conditional payment events. Messages may contain data inaccordance with a predetermined specification to insureinteroperability, such as the Eleanor specification. The data mayfurther be encapsulated in accordance with a transport protocol tofacilitate the transfer of the data over a network such as Internet 112.Standardized protocols include the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite. Those of ordinary skill inthe relevant art would appreciate that the particular network transferprotocol used to transfer the encapsulated transaction information isindependent of the nature of the encapsulated data itself that isgoverned by the particular electronic payment system specifications andvice versa.

Refer now to FIG. 2 illustrating, in flowchart form, a process 200 forprocessing concurrent conditional payment events in accordance with anembodiment of the present invention. Process 200 may, for example, beperformed by a BFI's electronic transaction system. The flowchartsprovided herein are not necessarily indicative of the serialization ofoperations being performed in an embodiment of the present invention.Steps disclosed within these flowcharts may be performed in parallel.The flowcharts are indicative of those considerations that may beperformed to produce the operations available to process conditionalpayment requests. It is further noted that the order presented isillustrative and does not necessarily imply that the steps must beperformed in the order shown.

Conditional payment status may be categorized into three categories:initial, intermediate and terminal. Initial status may be the startstatus of a payment condition, assigned automatically when a paymentrequest is first registered to the system. An initial status may bechanged to either intermediate status or terminal status by a request(equivalently, event), depending on the request type. A paymentcondition in an intermediate status may be further changed to terminalstatus. The status of a payment condition having terminal status may notbe changed into any other status. Events that trigger a statustransition, if occurring concurrently, are not necessarily of the samesignificance in the payment system. In step 202, concurrent events (fora particular conditional payment transaction) are queued in a priorityorder.

A prioritization scheme which may be used in conjunction with process200 is illustrated in the priority table in FIG. 3. The CDPProcessingstatus and the Failed status are in the intermediate category.“CDPProcessing status”, in accordance with the aforementioned Eleanorspecification may indicate that the CDP has accepted the particularpayment condition. “Failed” status may indicate that the CDP has notaccepted or cannot fulfill the condition. These statuses may be assigned“low” priority. “Waived” status, “Canceled” status, “Discharged” statusand “Expired” status are in the terminal category, and may be assigned“high” priority. “Waived” status may indicate that the paying party haswaived the condition. The “Waived” status “tells” the payment system toignore the condition. “Canceled” status indicates that the paymenttransaction itself has been cancelled by the buyer. “Discharged” statusindicates that the payment condition has been satisfied, and “Expired”indicated that the time for fulfilling the payment condition has lapsedwithout the condition being fulfilled. A methodology for enqueueingconcurrent events will be described in conjunction with FIG. 4.

Returning to FIG. 2 in step 204, process 200 waits, if the priorityqueue is empty. Otherwise, in step 206, the highest priority event, thatis, the event at the “top” of the queue, is removed from the queue andexecuted, step 206.

If the selected event executes successfully, step 208, if the event is aterminal event, step 209, the remaining events are deleted from thequeue, in step 210. In step 212, status messages are sent to therespective user, and process 200 terminates, step 218. Process 200 maysimilarly operate to process any other conditions in the paymentrequest. If, in step 209, the executed event is not a terminal event,events having the same priority are deleted from the queue, step 213.(As discussed below, a concurrent event may be added to the queue duringexecution of the current event.) In step 214, status messages arereturned to the respective users, and process 200 returns to step 204.

If the execution of the selected event fails, step 208, in step 214 astatus message is sent to the user. If the failure is recoverable, step216, process 200 returns to step 204. Otherwise, process 200 terminateswith respect to the current payment condition. Process 200 may similarlyoperate to process any other payment conditions.

Refer now to FIG. 4, illustrating in flowchart form, a process 400 forpopulating a priority queue, which may be used to perform the operationof step 202, FIG. 2. Process 400 may also be performed by the BFI'selectronic transaction system. Note that process 400 may be performed inparallel with process 200; in particular, concurrent events may be addedto the queue during the execution of an event. For example, process 400may be a separate thread continuously receiving events and enqueueingthem. However, it would be appreciated by those of ordinary skill in theart that process 400 may be implemented as a separate process withinterprocess communication (IPC) between process 200, FIG. 2, andprocess 400 for communicating data and actions between the twoprocesses. It would be further recognized that commonly-employed IPCmechanisms, such as pipes, may be used in conjunction with the presentinventive principles.

In step 402, the process enters a loop to enqueue concurrent conditionalpayment events. Note that, because event execution may take someduration of time, involving for example a database access and queueaccess, the set of unqueued events may change dynamically duringenqueueing and event execution. All such events received during thistime may be considered concurrent events. While there are unqueuedevents, step 402, an event is randomly selected and removed from a listof unqueued events in step 404. If the event has high priority, step406, in accordance with a predetermined priority, such as the prioritiesdefined in the priority table in FIG. 3, the selected event is insertedinto the front of the queue, step 408, and process 400 returns to step402. Otherwise the event is inserted into the end of the queue as a lowpriority event, step 410, and process 400 returns to step 402. Anyremaining events are enqueued by repeating steps 404-410.

Otherwise, in step 402, if there are no unqueued events, process 400loops until there is a new event. If there is a new event, the processbreaks out of the loop in step 402 and repeats the steps discussedabove.

Process 400 in conjunction with a set of priorities such as the prioritytable of FIG. 3 may be said to form a priority policy. It would beappreciated by those of ordinary skill in the art that other prioritypolicies may be used in conjunction with the present inventiveprinciples and such priority policies would fall within the spirit andscope of the present invention.

FIG. 5 illustrates an exemplary hardware configuration of dataprocessing system 500 in accordance with the subject invention. Thesystem in conjunction with the methodologies illustrated in FIGS. 2-4may be used for processing conditional payment requests in accordancewith the present inventive principles. Data processing system 500includes central processing unit (CPU) 510, such as a conventionalmicroprocessor, and a number of other units interconnected via systembus 512. Data processing system 500 also includes random access memory(RAM) 514, read only memory (ROM) 516 and input/output (I/O) adapter 518for connecting peripheral devices such as disk units 520 to bus 512,user interface adapter 522 for connecting keyboard 524, mouse 526,trackball 532 and/or other user interface devices such as a touch screendevice (not shown) to bus 512. System 500 also includes communicationadapter 534 for connecting data processing system 500 to a dataprocessing network, enabling the system to communicate with othersystems, and display adapter 536 for connecting bus 512 to displaydevice 538. CPU 510 may include other circuitry not shown herein, whichwill include circuitry commonly found within a microprocessor, e.g.execution units, bus interface units, arithmetic logic units, etc. CPU510 may also reside on a single integrated circuit.

Preferred implementations of the invention include implementations as acomputer system programmed to execute the method or methods describedherein, and as a computer program product. According to the computersystem implementation, sets of instructions for executing the method ormethods are resident in the random access memory 514 of one or morecomputer systems configured generally as described above. These sets ofinstructions, in conjunction with system components that execute themmay process conditional payment events in an electronic transactionsystem as described hereinabove. Until required by the computer system,the set of instructions may be stored as a computer program product inanother computer memory, for example, in disk drive 520 (which mayinclude a removable memory such as an optical disk or floppy disk foreventual use in the disk drive 520). Further, the computer programproduct can also be stored at another computer and transmitted to theusers work station by a network or by an external network such as theInternet. One skilled in the art would appreciate that the physicalstorage of the sets of instructions physically changes the medium uponwhich is the stored so that the medium carries computer readableinformation. The change may be electrical, magnetic, chemical,biological, or some other physical change. While it is convenient todescribe the invention in terms of instructions, symbols, characters, orthe like, the reader should remember that all of these in similar termsshould be associated with the appropriate physical elements.

Note that the invention may describe terms such as comparing,validating, selecting, identifying, or other terms that could beassociated with a human operator. However, for at least a number of theoperations described herein which form part of at least one of theembodiments, no action by a human operator is desirable. The operationsdescribed are, in large part, machine operations processing electricalsignals to generate other electrical signals.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions andalterations can be made herein without departing from the spirit andscope of the invention as defined by the appended claims.

1. (canceled)
 2. The computer program product of claim 3 wherein saidconditional payment events trigger a change in status of a conditionalpayment in said electronic transaction system.
 3. A computer programproduct in a tangible storage medium, the program product for processingconcurrent conditional payment events comprising programminginstructions for: enqueueing said concurrent conditional payment eventsin a queue according to a predetermined priority policy; executing anenqueued conditional payment event having a first priority position insaid queue; and deleting remaining conditional payment events having asame priority from said queues wherein conditional payment eventscomprise a predetermined set of requests for performing a correspondingaction on a conditioned payment in an electronic transaction system;wherein said step of deleting said remaining conditional payment eventsis bypassed if the executed conditional payment event fails.
 4. Thecomputer program product of claim 3 wherein said policy comprisesenqueueing each conditional payment event having a same priority inaccordance with a random selection.
 5. The computer program product ofclaim 4 wherein conditional payment events having a first priority areenqueued before conditional payment events having a second priority,wherein said first priority is higher than said second priority.
 6. Thecomputer program product of claim 2 wherein the status of a conditionalpayment comprises one of a predetermined set of statuses.
 7. Thecomputer program product of claim 6 wherein the predetermined set ofstatuses of a conditional payment comprises the group including:Registered, CDPProcessing, Failed, Waived, Canceled, Discharged andExpired.
 8. The computer program product of claim 6 wherein a firstsubset of the predetermined set of statuses comprises an intermediatecategory of statuses, and a second subset of the predetermined set ofstatuses comprises a terminal category of statuses.
 9. The computerprogram product of claim 8 wherein said policy comprises theintermediate category having a first priority and the terminal categoryhaving a second priority, wherein said first priority is lower than saidsecond priority. 10-19. (canceled)
 20. The data processing system ofclaim 21 wherein said conditional payment events trigger a change instatus of a conditional payment in said electronic transaction system.21. A data processing system for processing concurrent conditionalpayment events comprising: circuitry operable for enqueueing saidconcurrent conditional payment events in a queue according to apredetermined priority policy; circuitry operable for executing anenqueued conditional payment event having a first priority position insaid queue; circuitry operable for deleting remaining conditionalpayment events having a same priority from said queues whereinconditional payment events comprise a predetermined set of requests forperforming a corresponding action on a conditioned payment in anelectronic transaction system: wherein said step of deleting saidremaining conditional payment events is bypassed if the executedconditional payment event fails.
 22. The data processing system of claim21 wherein said policy comprises enqueueing each conditional paymentevent having a same priority in accordance with a random selection. 23.The data processing system of claim 22 wherein conditional paymentevents having a first priority are enqueued before conditional paymentevents having a second priority, wherein said first priority is higherthan said second priority.
 24. The data processing system of claim 20wherein the status of a conditional payment comprises one of apredetermined set of statuses.
 25. The data processing system of claim24 wherein the predetermined set of statuses of a conditional paymentcomprises the group including: Registered, CDPProcessing, Failed,Waived, Canceled, Discharged and Expired.
 26. The data processing systemof claim 24 wherein a first subset of the predetermined set of statusescomprises an intermediate category of statuses, and a second subset ofthe predetermined set of statuses comprises a terminal category ofstatuses.
 27. The data processing system of claim 26 wherein said policycomprises the intermediate category having a first priority and theterminal category having a second priority, wherein said first priorityis lower than said second priority.